The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to embodiments of the claimed inventions.
Message queuing and asynchronous processing implementations are capable supporting a significantly higher volume of concurrent messages without requiring special handling for the well known problems of deadlocks and race conditions. Not surprisingly then, asynchronous processing is found in many high-volume processing environments.
A message queue is simply a mechanism by which applications and discrete functional components may send messages between one another in order to reliably communicate. The message queue “broker” facilitates the message passing amongst such components by providing a protocol or interface accessible to the various services and components. For instance, the interface may be tied to a web based interface such that web based applications may communicate with and through the interface to originate messages and have those messages simply and reliably enqueued by the broker within the message queue. The broker will then handle further processing by distributing the message for processing and dequeuing the message at the appropriate time.
Thus, conventional solutions that implement asynchronous processing and message delivery commonly do so via a broker machine that accepts and enqueues incoming messages from a message producer or originator, distributes the queued messages one at a time for processing, and then dequeues the messages as appropriate.
While this model has proven successful in certain environments, it can nevertheless be improved upon. For instance, the conventional model is not fully transactional, lacks sufficient availability for high volume and high availability implementations, and wholly lacks any support whatsoever for bulk distribution, bulk processing, and bulk dequeuing of messages.
The present state of the art may therefore benefit from the systems and methods for implementing bulk handling in asynchronous processing as is described herein.